Businesses often have business processes which need to be tested to ensure that the organizational systems (e.g., personnel, computer, etc.) can support these business processes. The amount of testing performed for any given business process is usually correlated to the perceived criticality of that process in relation to other business processes. However, this can give rise to business processes that are not considered critical, but which are executed often. Alternatively, this may give rise to processes that are considered critical, but are execute d only occasionally. It would be of benefit to the organization to correlate the amount of testing of a given business process to the actual criticality of that process, as opposed to the perceived criticality.
In addition, resources are sometimes dedicated to testing business processes that are never used in practice. Conversely, business processes are sometimes used frequently in an organization, but never tested.
Also, there are many occasions during the testing phase of a product where the test fails, due to defects in the system, or perhaps due to environmental considerations (e.g., wrong versions of components, network problems, etc). These problems are therefore resolved during testing. Users encountering these problems in the field often turn to the system support personnel for help. Because the support personnel is generally not part of the testing team, they are unaware that similar symptoms have been encountered during testing and that there is a solution available.